![【レポート】クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そして組織 #AWSSummit](https://devio2023-media.developers.io/wp-content/uploads/2019/05/awssummit-2019-osaka.png)
【レポート】クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そして組織 #AWSSummit
こんにちは、青柳@福岡オフィスです。
AWS Summit Osaka 2019 のセッションレポートをお送りします。
セッション情報
- セッションタイトル
- クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そして組織
- スピーカー (敬称略)
- 株式会社ヌーラボ 木村 幸平 氏
- 株式会社ヌーラボ 吉岩 祐貴 氏
- セッション概要
ヌーラボの提供するオンライン作図ツール Cacoo では、変化するビジネスやユーザーのニーズに対応するため、 Kubernetes によるアーキテクチャのマイクロサービス化に取り組んでいます。今回は私たちがコンテナやマイクロサービスといったクラウドネイティブと呼ばれるアプローチによって解決しようとしている開発やインフラストラクチャー、組織上の課題と取り組みの内容、その成果についてご紹介します。
レポート
イントロダクション
- こんな方に
- コンテナ化を進めていきたい
- コンテナ化のメリットがわからない
- コンテナ化の先にあるものを知りたい
- クラウドネイティブってなに?
- ゴール
- コンテナ化の道筋を理解する
- クラウドネイティブに必要な要素を知る
- (Nulabについて知っていただく)
- Agenda
- Nulabについて
- クラウドネイティブとは
- CacooのKubernetes事例
- BacklogのKubernetes事例
Nulabについて ~ クラウドネイティブ開発の経緯
- Nulabについて
- 「チームで働くすべての人に」
- プロダクト: Backlog、Cacoo、Typetalk (すべてWebブラウザで利用できるサービス)
- Backlogの利用者は昨年100万ユーザーを突破
- Cacooは300万ユーザーが利用、特に海外での利用が多い (88%が海外ユーザー)
- クラウドネイティブ開発の経緯
- 利用者の増加、海外への展開に伴い、開発スピードやインフラ/組織をスケールさせたい
クラウドネイティブとは
- スケーラブルなアプリケーションを構築および実行するための技術の総称
- 代表的な技術
- コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型API
- 得られるもの
- 回復性(Resilient): アプリケーションがバグ等で停止してしまっても自動的に再起動する
- 管理しやすさ(Manageable): 統一的なAPIが用意されている等により、インフラエンジニアだけでなく開発者でも扱いやすい
- 可観測性(Observable): アプリの状態を外側から確認できる
- Cloud Native Trail Map
- 1) コンテナリゼーション: アプリのコンテナ化 (疎結合化、スケーラビリティの実現)
- 2) CI/CD: テスト、ビルド、デプロイの自動化 (手動ベースだとスピード感のある開発ができない)
- 3) オーケストレーション: Kubernetesなどの活用
- (ここでは最初の3つを紹介したが、全部で10段階ある)
CacooのKubernetes事例
- Cacoo
- ビジュアルコミュニケーションツール
- 特徴: ブラウザで作成、URLで共有、リアルタイムでコラボレーション
- Cacooの開発チーム: 福岡、ニューヨーク、アムステルダム
- 時差があるのでコミュニケーションにラグが生じる
- 場所毎に開発を分割するようにした
Kubernetes
- Kubernetesの特徴
- 複数のホストVMを抽象化、特定ホスト固有の運用管理が不要
- 段階的なKubernetesへの移行に2年かけた
- Step 1: EC2上でモノリシックなアプリ
- Step 2: 既存機能を切り出してECSのDockerコンテナ化
- Step 3: ECSのサービスをKubernetesへ移行
- Kubernetes移行の成果
- 依存関係の低下
- 部分的な変更がしやすくなった
- ビルドやデプロイが高速に
- チーム間が独立、責任範囲の分離
- 複数拠点での開発、チームのスケーリング、インフラのスケーリング
- 変動するビジネス要求への対応
BacklogのKubernetes事例
- Backlog
- 「チームではたらく、すべての人に」
- 開発者だけでなく、すべての職種の人が使えるツール
- 現在のBacklogのシステム構成
- 基本サービス: Scalaで実装、モノリシックなシステム
- 一部サービス: Goで実装、EC2上で稼働
- これらのサービスをまとめた「Service Cluster」を開発
- ユーザーにあわせてスケーラブル、DBも独立させ単一障害点をなくす
- 200以上のEC2インスタンス
- 運用はTerraform+Ansibleにより自動化 (Infrastructure as Code)
- 運用上の課題
- 物理ホストのメンテナンスは非常にコストがかかる
- リリースに要する時間もかかる
- → ユーザー増による運用コスト増を最小化したい
- 開発上の課題
- 巨大なコードベースによる予期せぬ不具合
- 思い切った変更に対する心理的な負担
- リリースの所要時間が長く、リリースサイクルを頻繁に回せない
- → コードベースの分割により開発効率を上げたい
EKS
- EKSとは
- マネージドKubernetes
- コントロールプレーンの管理が不要、アップデートも非常に容易
- IAMとの連係によるアクセスコントロール
- なぜKubernetes?
- いくつかのサービスは既にECSで稼働済み、コンテナのノウハウは蓄積しつつある
- Backlogの実行基盤の刷新を検討中: コスト増への対応
- CacooがKubernetesへ移行したので、Backlogもやってみよう
- なぜEKS?
- CacooチームがKubernetesのコントロールプレーンの管理に苦労していたのを見ていた
- なぜECSではない?
- Kubernetesの方が社内社外の情報が多い、OSSであるKubernetesの利点
- EC2、ECSのノウハウは既にあるので、新たな選択肢を増やしたい
- 仮にEKSでうまくいかなかったとしてもECSにすればよい、チャレンジとしてEKSを選択
- EKSで何をやっている?
- 新機能をEKSで開発、新機能のドッグフーディング
- 機能ごとに分割することを意識して開発、開発の効率化、オーナーシップの明確化
- リリース時間を短縮、リリースサイクルを早められた
- メインサービスは新機能を呼び出すコードのみ追加、新機能追加による影響を最小化した
- 課題: モノリシックな既存サービスをどう移行するか
- EKSでの運用
- 既存で採用しているTerraformを、EKSの管理でも使用
- terraform applyコマンドにより無停止でAMIを更新可能
- セキュリティインシデントへの素早い対応が可能に
- 今後
- Backlogをもっと使い易くするため、EKSによる実行基板の刷新を検討
感想
「Backlog」「Cacoo」はAWS Summitに参加している方の中にも利用者が多いのではないでしょうか。そういった身近なツールの開発の裏側を聞くことができて、とても興味深いセッションでした。
KubernetesやECS、EKSを採用した経緯、段階的に新しい技術を取り入れていく過程など、コンテナオーケストレーション技術を使っていくにあたって参考にしたいと思います。